クラスメソッドで働く若手AWSエンジニアによる転職ガイド
クラスメソッドAWS事業部所属の阿部 洸樹です。
現職は2015年10月にJoinしました。年数でいうと3年目です。
"転職ガイド"など銘打ってみましたが、人にアドバイスできるほど転職していませんし、そんな立場でもありません。
私が転職の前後で考えていたことや今考えている事を共有したら、AWSエンジニアにjob changeしようとしているかたの参考になるかもと思い筆を取ることにしました。
私は事業部の最年少（多分）なので、若手エンジニアの参考になるもしれません。
AWSエンジニアやクラスメソッドに興味のある方は、読んでみてください。
内容は私の主観によるものが多いです。
転職前のこととそのきっかけ
前職の経歴
新卒で入社した前職は主にプライベートクラウドの構築と運用を行なっていました。
職種でいうとインフラエンジニアで運用の比重が多かったです。
サーバー構築、問い合わせ対応、障害対応などを行なっていました。
技術的なワードをいくつかあげてみましょう。
ESX、Windows、Linux、ルータ、L2/L3スイッチ、ファイアウォール、UTM、NASといった感じです。
当時はLPICやCCNAを勉強していたのですが、時々実務に役立つ場面がありました。
メールサーバーの障害では障害原因が複数ある中、LPICの勉強で覚えたコマンドで1つ1つ紐解いて解決できました。
机上の勉強と実務が一致した時に深いやりがいを感じていました。
資格取得だけでなく、何か出来ないかなーと思った時に手に取ったのがソフトウェアデザインという雑誌でした。
私が手に取った時はInfrastructure as Codeが特集されていたと思います。
Chef、CloudFormationなど全く知らなかった技術との出会いでした。
同じ頃に業務でAWSと出会いました。
私が担当したのは単純な業務だったのですが、すぐに魅力に気づき個人アカウントを作りました。
はじめにやったのは、EC2、RDSを使ったWordPressの構築です。
データセンターに行って機器の入れ替えなども行なっていた自分からすると、Webブラウザでぽちぽちするだけでサーバーがローンチするスピード感は衝撃でした。
AWSとの出会い、雑誌やtwitterから入ってくる情報量を前にこのままでは置いていかれるのでは？という焦りから転職を考えはじめました。
転職を考えてから
AWSエンジニアに興味を持ってからの会社選びは恥ずかしい話ですが、まずはホームページの雰囲気で選択しました。
雰囲気でクラスメソッドをピックアップしてから、Developers.IO 2015に参加しました。
Developers.IOはクラスメソッドの社員が技術セッションを行うイベントです。
IT系勉強会というとわかりやすいでしょうか。
勉強会に参加する事もはじめてだった私にとっては、これもまた衝撃でした。
以降何度かJAWS-UG（AWS Users Group - Japan）に参加するなどして、よりAWSエンジニアへの興味を持つようになりました。
参考: 【好評御礼】DevelopersIO2017の全セッション概要紹介！ #cmdevio2017
当時のクラスメソッドは今ほど会社説明会を行なっておらず、外から見てよくわからない会社だったと思います。
なお、現在は定期的に開催されているのでぜひお越しいただきたいです。
ブログを書いている事は認識していました。
ブログを書くことについて不安はありましたが、置いていかれる焦りを感じていた身としてはむしろ歓迎といった気持ちでした。
あまり深く考えていなかったのでは？と言われるとそうかもしれません。
いずれにせよ、入社試験を受けて2015年10月に当時のAWSコンサルティング部（現 AWS事業部）にJoinしました。
現職1年目
私の一番大きな役割は、AWS環境の構築とコンサルティングです。
この役割は1年目から変わっていません。
メンターのような形で3ヶ月ほどフォローして頂く期間があってから、1人で案件を回すようになったと思います。
AWS事業部の特徴として、誰かが事細かに業務指示をしてくれるといった事は基本的にありません。
自ら課題を発見し能動的に提案し実行しアピールする事が求められます。
業務にあたって誰かの指示や承認をもらっていた事を自覚した瞬間でした。
1年目はそういったギャップに苦しんだ期間だったと思います。
組織に貢献できているのかという不安を抱えつつ仕事していました。
セキュリティチームへのJoin
ある日、道を歩いていると部長と同僚に囲まれセキュリティチームに勧誘されました。
事業部内にはタスクフォースと呼ばれる、メイン業務とは別のミッションをもったチームがいくつかあります。
セキュリティチームはタスクフォースの1つです。
弊社のセキュリティサービスやセキュリティ製品の導入を主管しています。
結果的にこの勧誘は幸運な出来事でした。
現職2年目
2年目は少しずつ自信をつけはじめた時期でした。
当時書いたAmazon VPC IPアドレス設計レシピというとても基本的な事を書いたブログではてブをたくさん貰えた事が嬉しかったです。
基本的な事を共有しても喜んでもらえるんだという発見でした。
セキュリティについて考え、楽しくまたモヤモヤした時期でもありました。
セキュリティという言葉が小難しく使われており、「結局何したら良いのかわかりづらくなっている」と懸念していました。
登壇する立場で参加したDevelopers.IO 2017では、AWSセキュリティの全般を語ろうと試みました。
Developers.IO 2017セッション「ここからはじめるAWSセキュリティ」で話しました #cmdevio2017
小さな成功体験
2年目の終わり頃から、自分がこうすべきと思う事をそのままやってみることにしました。
自分が不満に感じる事の多くについて同僚も不満に感じているいうことに気がついたからです。
具体例を出すと、社内のある報告ページは私が作り私が使いはじめました。
チャットで報告をすると発言が流れてしまい組織として共有できない。また、弱い共有になってしまうという不満があったからです。
私は同僚に報告ページを作るようにお願いした事はないのですが、気がついたら報告ページを作る運用になっていました。
現在では報告ページに関する一連のフローが整備されています。
事業部の方針に「自由に提案しオーナーシップとリーダーシップを持って自分で遂行」とあるのですが、これは小さな成功体験だと思っています。
ブログでの読者のレスポンスや改善活動の小さな成功体験が自信に繋がりました。
現職3年目
3年目とは今のことです。
今担当している業務を中心にお話しましょう。
AWS環境の構築とコンサルティングがメイン業務です。
サブタスクとして、セキュリティチームと構築改善活動を行なっています。
セキュリティチームとしての活動と今後
セキュリティチームとしての活動は私のブログがわかりやすいと思います。
Deep SecurityやSophos、F-Secureなどの導入/検証やセキュリティソリューションの説明などを行なっています。
今後はよりお客様にセキュリティの価値を届けることにこだわって活動したいと考えています。
構築改善チームの立ち上げ
構築改善はAWS事業部が抱える課題を解決するためにはじめた活動です。
私がリーダーとして活動しています。
特に要望された訳ではなく勝手にはじめて、メンバーを募りました。
今後考えが変わるかもしれませんが、ある課題があるときに簡易的にでも文章化する事が重要だと考えています。
文章化されている事で課題が適切に共有され、議論が進むからです。
文章化されていないとそもそも何が課題なのかがはっきりせず、また人によって認識がずれてしまうと感じています。
活動がスタートした頃は"みんな不満があるが何をすればいいのかわからない"といった状況で、自信を失う事が多々ありました。
そこで文章化は手間ですが、誤字の修正などの小さな事でも成果にすることにしました。
小さな成功体験が自信に繋がると考えたからです。
現在は議論も活発になり、アウトプットの出せるチームになっていると思います。
今後は、新しい施策を回していけるようなチームに出来ればと考えています。
AWSエンジニアへの転職を考えているかたに
転職は人生への影響が大きいため、気軽に転職してみて下さいと言うのは不誠実な気がします。
ただ、この記事を見て下さっているかたはAWSや弊社に興味を持っていると思うので、チャレンジしてみて欲しいです。
クラウドの登場によって、ITの変化は急激に加速したと思います。
たった5年後のITはもはや未知の世界です。全く予想できません。
AWSに関わるという事は、クラスメソッドに限らずその変化に身を置くことになるでしょう。
新しい技術やサービスを楽しめるエンジニアにとっては、とてもハッピーな体験になるはずです。
AWS事業部に興味があるかたは以下をご覧ください。
きちんと事実が書いてあるので、参考になると思います。
AWSエンジニアへのJob Changeを迷うかたへ
AWSの経験が浅いかたは、活躍の場があるのか心配だと思います。
現在は、AWSエンジニアのように未経験の方の採用も行なっています。
組織としても成長してきて、受け入れ体制は整ってきています。
それでも迷っているかたは、JAWS-UGに参加したり、個人でAWSアカウントを取得して色々試してみてはいかがでしょうか。
AWSの魅力にはまっていくかもしれません。
AWSの急激な変化を考えると、魅力を感じた時点でJoinするのが得策だと思います。
AWSエンジニアへの転職を考えている若手エンジニアに向けて
クラスメソッドのAWS事業部の平均年齢は大体30代中盤です。
私は20代ですが年齢を気にした事がありません。恐らく先輩方も気にしてないと思います。
先輩という言葉は普段使いません。さん付けで呼んでいます。
非常にフラットな組織です。
一緒に「自由に提案しオーナーシップとリーダーシップを持って自分で遂行」を実践出来ればとても嬉しいです。
オーナーシップとリーダーシップを持った人が複数人いると、大きな成果に繋がるからです。
クラスメソッドを選ばない場合でも、ブログや勉強会などで繋がれたら嬉しいです。
おわりに
転職ガイドといいつつ、自分の経験や考えている事をただ書いただけになってしまいました。
参考になった部分があれば嬉しいです。
クラスメソッドに興味がある場合、このブログをウォッチして欲しいです。
会社説明会の告知があるはずです。ぜひお越しください。
実際の応募は、現在募集中の職種をご覧いただき、エントリーください。
応募フォームの紹介者に私の名前を書いていただくと、良い事があるかもしれません。
![[アップデート] Amazon QuickSight へロゴやテーマカラーを設定するための「ブランド管理機能」が追加されました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-19e77b9a51519e08b94d0f688c125729/4f439c75e1ee56c70e315fa46fa45f81/amazon-quicksight)
